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Abstract 

This  paper  presents  the  C2  Enterprise  Reference  Architecture  (C2ERA),  which  is  a  new  technical 
concept  of  operations  for  building  information  systems  better  suited  to  the  NCW  environment. 
The  C2ERA  is  the  technical  architecture  mandated  by  the  Designated  Acquisition  Commander 
for  C4ISR  Enterprise  Integration  in  the  U.S.  Air  Force.  The  C2ERA  contains  two  key  ideas. 
Related  activities  and  functions  are  gathered  into  a  C2  Node,  with  a  designated  node  manager 
responsible  for  delivering  and  sustaining  an  integrated  capability  to  the  user  community.  The 
development  of  mission  functionality  is  separated  from  the  system  infrastructure.  This 
infrastructure  (and  the  responsibility  for  it)  is  divided  into  one  part  which  must  be  the  same 
across  the  enterprise,  called  the  Common  Integrated  Infrastructure,  and  another  part  which  may 
vary  between  C2  Nodes,  called  the  node  platforms. 

1.  Introduction 

Network-centric  warfare  is  about  effective  networking  of  the  warfighting  enterprise,  leading  to 
increased  combat  effectiveness.  This  “networking”  involves  much  more  than  physical 
communication  links  between  people  and  the  information  systems  they  use.  Information  systems 
used  in  NCW  must  also  support  effective  networking  in  the  information  and  cognitive  domains. 
These  systems  must  therefore  work  with  each  other  to  produce  coherent  information,  fusing 
many  separate  facts  into  a  “common  picture”  of  the  environment.  The  systems  must  also  help 
their  users  work  with  each  other  to  collaborate  and  synchronize  operations.  Finally,  because  we 
do  not  always  know  in  advance  precisely  what  information  will  be  needed  and  what  user 
collaborations  must  be  supported,  we  require  information  systems  that  can  be  quickly  changed  as 
required. 

In  short,  what  users  need  are  information  systems  that  are  both  cohesive  and  flexible.  In  their 
ideal  vision,  users  would  like  something  which  from  their  perspective  appears  as  a  single 
seamless  system,  doing  exactly  what  they  want  done  today,  and  easily  changed  to  do  what  they 
will  want  done  tomorrow.  This  presents  a  challenge  to  system  developers.  The  old  way  of 
building  systems  produced  “stovepipes”  which  might  support  the  needs  of  its  particular  users, 
but  which  did  not  work  well  with  other  systems  and  were  not  at  all  easy  to  modify. 

In  this  paper  we  will  describe  the  challenges  faced  by  the  system  developers,  explain  the 
shortcomings  of  the  former  development  paradigm,  and  explain  why  the  C2ERA  is  a  superior 
technical  approach  for  designing,  acquiring  and  integrating  the  information  systems  of  the  NCW 
Enterprise. 
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2.  The  C2  Enterprise  Integration  Problem 


What  the  users  want  to  have  is  completely  transparent  technology,  integrated  into  a  single  perfect 
C2  information  system.  This  ideal  system  would: 

•  Do  exactly  what  they  need  today, 

•  Be  easy  to  change  into  what  they  need  tomorrow, 

•  Have  all  parts  working  together  as  a  seamless  whole,  allowing  users  to  do  the  same,  and 

•  Be  affordable,  delivered  on  schedule,  delivered  on  budget,  etc. 

We  couldn’t  build  that  perfect  system  yesterday,  nor  can  we  build  it  today,  and  we  don’t  have  a 
plausible  roadmap  for  ever  building  that  system.  The  fundamental  problem  is  complexity. 
Perfect  integration  would  require  too  many  people  to  comprehend  too  many  details.  Arranging 
the  necessary  group  knowledge  is  beyond  our  capacity  today,  and  in  the  foreseeable  future. 

It  is  therefore  necessary  to  make  a  compromise,  accepting  imperfect  integration  to  reduce  the 
complexity  to  something  manageable.  The  compromise  in  the  past  has  been  to  partition  the  C2 
enterprise  into  many  separate  systems,  managed  independently  by  separate  program  offices. 
Each  program  office  built  a  system  to  satisfy  the  needs  of  its  users  alone.  Each  program  office 
built  the  mission  functionality  desired  by  the  users:  things  like  air  mission  route  planning  tools, 
or  air  refueling  capacity  calculators.  Each  program  office  also  built  the  system  infrastructure 
they  required:  things  the  users  do  not  desire,  such  as  networks  and  database  management 
systems,  but  which  are  needed  to  support  the  functionality  the  users  do  desire.  Mission 
functionality  and  infrastructure  were  built  and  delivered  as  a  single  tightly  integrated 
amalgamation,  making  it  nearly  impossible  to  deploy  a  subset  of  the  mission  functionality  or  to 
replace  a  subset  of  the  infrastructure  with  new  technology.  The  infrastructure  implementations 
were  highly  optimized  for  a  specific  set  of  mission  functions  and  a  specific  set  of  users,  making 
it  difficult  for  any  other  program  to  reuse  the  infrastructure  platform.  Technical  architectures 
and  management  approaches  used  to  acquire  C2  systems  were  also  organized  and  structured  to 
support  the  production  and  sustainment  of  separate  C2  systems. 

In  short,  the  past  compromise  approach  built  systems  which  met  the  needs  of  small  user 
communities,  but  which  were  hard  to  change  and  hard  to  make  work  with  other  systems.  This 
compromise  does  not  fit  well  with  NCW,  which  demands  seamless  and  dynamic  connectivity 
between  people  in  the  information  and  cognitive  domains.  As  a  result  we  see  symptoms  of 
interoperability  problems: 

•  Hard  to  make  new  connections  and  exchange  C2  information  among  separate  C2  systems, 
since  interfaces  were  specified  by  individual  pair-wise  agreements. 

•  Hard  to  administer  groups  of  C2  systems,  since  each  system  was  designed  and  configured 
independently. 

•  Hard  to  manage  change  in  C2  systems  and  functions,  since  interfaces  were  optimized  for 
specific  configurations. 

So  our  current  acquisition  approach  and  technical  architectures  are  not  going  to  be  effective  in 
delivering  on  the  promise  of  NCW. 


3.  The  C2ERA  Solution 


The  C2  Enterprise  Reference  Architecture  (C2ERA)  was  developed  to  address  the  issues 
associated  with  delivering  C2  systems  that  can  support  NCW.  It  is  a  different,  better 
compromise  between  integration  and  complexity,  made  possible  by  new  and  better  information 
technology.  Instead  of  a  single  grand  integration  covering  the  whole  C2  enterprise,  we  follow  a 
decentralized  approach  to  integration,  focusing  on  technical  convergence  on  elements  which  are 
larger  than  individual  programs  but  smaller  than  the  whole.  The  two  key  ideas  in  the  C2ERA 
are: 

•  Gathering  related  activities  and  functions  into  a  C2  Node,  with  a  designated  node  manager 
responsible  for  delivering  and  sustaining  an  integrated  capability  to  the  user  community.  A 
C2  Node1  is  a  major  operational  element  of  the  NCW  Enterprise  and  comprises  a  collection 
of  activities  and  functions  which  the  operational  community  uses  as  a  major  warfighting 
component. 

•  Separating  the  development  of  mission  functionality  from  the  system  infrastructure.  This 
infrastructure  (and  the  responsibility  for  it)  is  divided  into  one  part  which  must  be  the  same 
across  the  enterprise,  and  another  part  which  may  vary  between  C2  Nodes.  Information 
exchange  between  nodes  is  specified  by  node  independent  mechanisms  that  enable  loose 
coupling  and  provide  least  common  denominator  interfaces  that  all  nodes  can  implement. 

The  C2ERA  brings  us  closer  to  the  NCW  ideal.  It  improves  cohesion  by  gathering  together 
things  that  used  to  be  separate:  the  related  mission  applications.  It  improves  flexibility  by 
separating  things  that  used  to  be  irretrievably  mixed:  the  mission  functionality  and  the 
infrastructure. 

The  C2ERA  supplies  a  technical  design  pattern  to  program  office,  contractor  and  user  architects 
and  developers.  Its  goal  is  to  guide  and  constrain  key  system  integration  and  interoperability 
decisions.  It  describes  the  partitioning,  roles,  and  interfaces  among  the  three  technical  elements 
of  the  enterprise.  The  C2ERA  describes  an  enterprise  architectural  plan,  one  that  subscribes  to 
common  standards,  identifies  critical  integration  points,  utilizes  pervasive  commercial 
technologies,  reduces  development  risk  and  is  based  on  a  computing  services  approach. 

The  C2ERA  distinguishes  between  integration  and  interoperability  appropriately,  and  seeks  to 
use  each  appropriately.  Integration  is  the  intimate  technical  junction  of  C2  systems  for  closely 
related  functions.  Interoperability  is  the  discrete  linkage  and  sharing  of  information  among  C2 
systems  across  the  entire  NCW  Enterprise. 

The  C2ERA  is  intended  to  support  platform  evolution  and  technology  insertion.  Given  the 
change  and  flexibility  implications  of  NCW,  identical  solutions  across  the  enterprise  will 


1  This  usage  of  the  term  “node”  is  slightly  different  from  the  DoD  Architecture  Framework  OV2  “Operational  Node  Connectivity  Description”  in 
that  OV2  nodes  are  defined  for  operational  reasons  based  on  current  or  past  CONOPS  with  no  other  criteria. 


generally  be  impractical  and  non-optimal.  C2  systems  must  be  loosely  coupled  so  that  the  triad 
of  systems,  organizations  and  processes  can  evolve  and  change  rapidly. 


The  problems  of  semantic  agreement  and  data  management  are  not  addressed  by  the  C2ERA.  It 
does  not  require  data  integration,  database  consolidation,  or  the  designation  of  “authoritative 
sources”  of  data.  We  understand  that  these  activities  must  happen  as  part  of  enterprise 
integration,  but  they  are  out  of  scope  for  the  C2ERA. 

4.  Changing  How  We  Organize  Acquisition  -  The  C2  Node  Approach 

A  C2  Node  is  a  collection  of  applications  and  infrastructure  that  is  implemented  to  execute  a  set 
of  operational  capabilities.  C2  Nodes  can  be  treated  as  “black  boxes”  at  the  Enterprise  level. 
This  allows  for  a  high  degree  of  flexibility  to  the  individual  C2  systems  developers  and  allows 
each  C2  Node  to  evolve  independently.  C2  Node  boundaries  are  defined  for  operational  reasons 
and  as  strategically  selected  integration  points  to  implement  cross-mission  and  cross-capability 
integration.  By  intension,  a  C2  Node  is  a  cohesive  weapon  system  used  by  a  collection  of  people 
to  perform  capabilities.  It  is  not  constrained  to  current  operational  practices.  In  order  of 
importance,  a  good  C2  Node: 

•  Displays  operational  cohesion:  it  serves  a  group  of  users  who  need  to  collaborate  closely  to 
perform  their  missions. 

•  Displays  implementation  cohesion:  it  collects  and  integrates  mission  applications  which 
must  work  together  seamlessly  to  support  the  users.  Integration  efforts  proceed  with 
identifying  functional  interactions  and  inter-exchanges  that  necessitate  application  level 
integration.  This  is  as  opposed  to  a  random  or  system  vendor  driven  application  approach. 

•  Displays  infrastructure  cohesion:  it  collects  mission  applications  which  can  be  implemented 
using  the  same  "C2  Node  Platform"  infrastructure.  We  want  to  avoid  grouping  applications 
with  wildly  different  infrastructure  needs. 

The  best  ways  to  map  capabilities  to  C2  Nodes  will  be  through  an  iterative  process,  a  co¬ 
evolution  of  technology,  doctrine,  and  organization.  With  the  current  operational  and  technology 
constraints,  C2  Nodes  will  be  something  akin  to  an  OPFAC.  Below  this  level  the  Node  Manager 


Attributes  of  the  C2  Node  as  a  Weapon  System 

•  Defined  operational  role  as  an  element  of  the  NCW  Enterprise 

•  Single  overall  acquisition  manager  with  responsibility  and  authority 

•  Optimized  as  an  entity  across  all  the  system  components 

•  Integrated  components  within  the  weapon  system 

•  Training  as  an  integral  component,  including  tools,  simulators,  etc.  as  appropriate 

•  Significant  test  &  validation  process  prior  to  deployment 

•  Complete  DOTMLPF  analysis  developed  prior  to  deployment 

•  Boundaries  of  valid  usage  established  prior  to  deployment 


is  responsible  for  “Nodal”  Integration.  He  or  she  is  responsible  for  reducing  the  system 
administration  burden,  integrating  functions  within  the  C2  Node  and  across  domains  and 
providing  a  cost  effective  nodal  infrastructure  to  system  developers.  He  or  she  is  also 
responsible  for  coordinating  with  other  node  managers  and  the  Enterprise  Manager.  In  this  way 
there  are  far  fewer  integration  points  and  there  is  a  person  responsible  for  each  of  them. 

5.  Changing  How  We  Build  Systems  -  Separating  Functionality  and  Infrastructure 

The  second  element  of  the  C2ERA  approach  is  to  separate  the  mission  functionality  from  the 
underlying  IT  infrastructure.  Most  programs  will  now  build  mission  functionality  that  rides  on 
and  integrates  with  infrastructure  components  built  and  supported  by  other  programs.  By  this 
partitioning  into  a  layered  approach,  mission  function  oriented  programs  can  focus  on  satisfying 
warfighter  requirements,  infrastructure  programs  can  focus  on  satisfying  mission  function 
requirements,  and  we  can  avoid  excessive  coupling  between  functionality  and  infrastructure. 

We  believe  it  is  necessary  to  make  one  further  separation,  dividing  the  infrastructure  into  one 
part  which  must  be  the  same  across  the  enterprise,  and  another  part  which  may  vary  between  C2 
Nodes.  The  resulting  architecture  is  shown  in  the  following  diagram. 
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5. 1  Why  the  Infrastructure  Must  Be  Divided 

A  “one  size  fits  all”  infrastructure  is  not  practical  for  the  entire  C2  Enterprise.  Such  an 
infrastructure  would  be  difficult  to  build,  since  the  range  of  requirements  would  be  large.  It 
would  be  difficult  to  evolve,  since  all  the  nodes  would  have  to  be  modified  as  the  infrastructure 
changed.  It  would  be  virtually  impossible  to  optimize  the  infrastructure  across  the  enterprise. 
For  this  reason  we  placed  part  of  the  infrastructure  under  the  control  of  the  node  manager.  This 
is  the  node  platform.  The  C2ERA  specifies  a  list  of  services  (available  in  [1])  that  must  be 
provided  by  the  node  platform;  implementation  choices  -  usually  between  COTS  products  -  are 
up  to  the  node  manager. 

However,  node  managers  cannot  be  in  control  of  the  entire  infrastructure.  In  order  for  the 
enterprise  to  function,  some  basic  capabilities  must  be  the  same  across  the  enterprise.  These  are 


called  “enterprise  services,”  and  collectively  they  make  up  the  Common  Integrated 
Infrastructure  (CII).  Node  managers  and  application  developers  are  required  to  use  the  CII 
services;  separate  implementations  are  forbidden. 

5.2  Services  That  Belong  in  the  CII 

CII  services  are  those  that  must  be  the  same  throughout  the  enterprise  to  avoid  interoperability 
“seams”  that  would  block  the  flow  of  information.  CII  services  may  be  defined  as  those  having 
the  following  properties: 

•  Enterprise  essential  -  the  enterprise  won’t  work  without  it. 

•  Enterprise  control  -  the  rules  for  operation  and  administration  must  be  the  same;  node 
managers  have  no  autonomy  (or  limited  autonomy). 

•  Enterprise  scale  -  the  service  must  be  capable  of  handling  every  enterprise  participant. 

•  Enterprise  connectivity  -  it  must  be  the  same  service  throughout  the  enterprise.  For  example, 
the  network  communications  service  connects  every  enterprise  participant;  we  don’t  have 
two  or  more  disconnected  networks. 

•  Enterprise  content  -  the  service  returns  the  same  result  for  the  same  request  throughout  the 
enterprise. 

The  Domain  Name  Service  (DNS)  is  a  good  illustration  of  an  enterprise  service  that  belongs  in 
the  CII.  DNS  is  the  Internet  service  that  translates  network  host  names  (e.g.  “www.acc.af.mil”) 
to  network  IP  addresses  (e.g.  “131.6.12.199”).  The  properties  of  DNS  that  make  it  a  good  CII 
service  are: 

•  DNS  is  a  service.  Mission  applications  call  the  service  to  translate  host  names;  the  service 
returns  the  network  address. 

•  DNS  is  essential.  For  example,  web  browsers  cannot  work  without  DNS;  they  would  have 
no  way  to  resolve  URLs. 

•  No  one  should  build  their  own  independent  DNS.  Everyone  should  use  the  service  provided 
by  the  enterprise.  (In  this  case,  the  “enterprise”  is  managed  by  the  Internet  Corporation  for 
Assigned  Names  and  Numbers,  ICANN.) 

•  DNS  must  be  available  throughout  the  enterprise. 

•  It  must  be  the  same  DNS,  returning  the  same  content,  throughout  the  enterprise. 

•  The  DNS  content  is  created  by  many  people. 

•  The  rules  for  connecting  DNS  servers  and  for  creating  DNS  content  are  the  same  throughout 
the  enterprise. 

5.3  Attributes  of  the  Enterprise  Services 

We  require  certain  technical,  operational,  and  business  properties  in  our  enterprise  services  in 
order  to  make  them  dependable  and  easy  to  use.  Enterprise  services  will  always  have  a  least- 
common-denominator  service  specification,  one  which  makes  the  fewest  possible  assumptions 
about  the  node  platform  infrastructure.  This  avoids  infrastructure  coupling  and  preserves  the 


node  manager’s  autonomy.  The  enterprise  service  provider  will  typically  supply  APIs, 
development  tools,  SDKs,  etc.  to  support  node  platform  and  mission  application  developers.  Key 
performance  parameters  are  defined,  including  response  times,  reliability,  security,  availability, 
other  “ilities”  as  well  as  standard  certifications  such  as  C4ISP,  CTO,  CON,  etc.  Enterprise 
services  are  managed  and  available  24x365.  Each  service  has  an  on-going  O&M  commitment, 
provides  cost,  resource  and  licensing  agreements. 

6.  Relationship  of  the  C2ERA  to  the  Global  Information  Grid 

The  C2ERA  was  initially  developed  by  the  Air  Force  as  a  way  to  provide  a  more  detailed  (design 
pattern)  guidance  to  government  program  offices  and  system  developers  to  ensure  that  an 
integrated  enterprise  vision  as  outlined  in  the  Global  Information  Grid  (GIG)  architecture  would 
be  achieved. 

C2ERA  provides  a  layered  structure  that  takes  advantage  of  current  commercial  industry 
approaches  to  support  network  centric  operations.  It  provides  guidance  to  AF  developers  such 
that  they  can  acquire  and  integrate  enterprise  level  capabilities.  The  AF  has  shared  the  C2ERA 
with  DISA,  Army  and  Navy  partners  and  has  also  offered  this  to  the  GIG  V2  effort. 

The  GIG  and  the  C2ERA  are  mutually  beneficial  and  necessary.  The  GIG  is  a  higher  level 
definition  of  architecture  vision  to  support  NCW.  The  C2ERA  is  a  necessary  and  more  detailed 
design  pattern  for  NCW  and  enterprise  interoperability.  Efforts  should  be  taken  in  the  future  to 
ensure  that  these  architectures  evolve  as  companion  documents. 

7.  Challenges 

Adopting  the  C2ERA  is  more  than  just  a  change  in  technical  direction  and  detail.  The  C2ERA 
approach  changes  some  basic  acquisition  concepts: 

•  Integration,  especially  enterprise-level  integration,  takes  work.  Somebody  has  to  do  it.  The 
C2ERA  approach  moves  much  of  that  work  from  deployment  to  development.  Our  current 
stovepipe  C2  systems  force  the  units  setting  up  a  C2  facility  to  do  the  detailed  integration  of 
the  individual  systems.  C2ERA  moves  much  of  that  responsibility  to  the  Node  Manager  as 
part  of  the  acquisition  process. 

•  The  role  of  the  Node  Manager  introduces  a  new  relationship.  The  requirement  for  individual 
C2  systems  to  be  integrated  into  the  node  reduces  the  autonomy  of  the  programs,  since  it  can 
add  dependencies  on  things  the  programs  now  control.  It  imposes  constraints  of  complying 
with  an  externally  provided  infrastructure  where  programs  are  now  free  to  choose  their  own 
infrastructure. 

As  the  Air  Force  moves  forward  to  adopt  and  institutionalize  the  C2ERA,  the  acquisition 
community  needs  to: 

•  Develop  and  mature  enterprise  acquisition  processes  to  support  enterprise-level  analysis. 

•  Develop  and  mature  processes  and  policies  to  empower  the  Node  Manager. 

•  Engage  the  programs  to  identify  capabilities  that  should  be  provided  as  enterprise  services 
versus  node  platform  components. 


•  Engage  with  industry  to  identify  opportunities  for  standardization  of  node  platform 
components. 

•  Identify  program-specific  solutions  that  can  be  evolved  and  expanded  to  satisfy  enterprise 
requirements. 

•  Develop  migration  strategies  for  programs  to  move  to  enterprise  solutions  when  they  become 
available. 

8.  Conclusion 

NCW  requires  new  approaches  to  Enterprise  Integration.  For  the  NCW  Enterprise  to  deliver  on 
its  promise,  we  need  to  deliver  warfighter  capabilities  with  “Enterprise  Inside.” 

The  Air  Force  C2ERA  is  a  basic  design  pattern  for  NCW  Enterprise  Integration.  It  partitions  the 
enterprise  into  Applications,  Nodes  and  Common  Infrastructure  (CII)  that  is  made  practical  by 
advances  in  IT  technology.  The  resulting  architecture  provides  a  better  compromise  than  a  C2 
system-centric  approach,  but  is  not  perfection.  It  improves  cohesion  among  things  that  need  to 
work  together,  while  reducing  coupling  among  things  that  should  change  independently. 

The  C2ERA  focuses  on  developing  a  small  manageable  set  of  integration  points  for  the  NCW 
Enterprise.  These  must  allow  information  to  flow  efficiently  while  providing  acquisition 
flexibility  to  incorporate  the  latest  and  ever-evolving  technologies.  Trying  to  manage  at  the 
Program  level  will  not  achieve  this.  C2  Nodes  offer  an  intermediate  integration  activity  that  is  a 
compromise  between  trying  to  integrate  and  manage  a  large  number  of  constantly  changing 
systems  and  trying  to  integrate  by  requiring  that  all  development  activities  use  the  same 
products. 
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Appendix  -  A  C2  Node  /  C2ERA  Taxonomy 


Capability 

Application 

Domain 

C2  Node  capability 
C2  Node  proponent 
C2  Node 

C2  Node  manager 
C2  Node  platform 
C2  Node  admin 
C2  Node  users 
C2  Facility 
C2  Facility  manager 
CII  manager 
CII  Cluster 
CII  Cluster  operator 


Something  that  gets  done  (operational) 

Something  that  gets  built  to  execute  a  capability 

Collection  of  similar  capabilities  which  is  convenient  and  useful 
for  business  purposes 

Collection  of  capabilities  with  an  intended  operational  result 

User  reps  that  choose  the  collection  of  things  done 

Collection  of  applications  &  infrastructure  that  gets  built  to 
execute  a  C2  Node  Capability 

Manager  for  building  &  deploying  a  C2  Node 

The  infrastructure  that  supports  a  particular  C2  Node 

Manager  for  administering  a  C2  Node 

The  people  performing  the  C2  Node  capabilities 

Location  for  executing  capabilities 

Manager  for  the  location 

Manager  for  building  &  deploying  the  CII 

That  part  of  the  CII  that  is  deployed  at  a  C2  Facility 

Manager  for  administering  a  CII  cluster 
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C2  Enterprise  Reference  Architecture  (C2ERA) 


•  What  problem  does  C2ERA  try  to  solve? 

•  What  are  the  key  aspects  of  the  solution? 
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C2  users  would  like  to  have 
a  single  perfect  02  system 

-  It  does  exactly  what  they 
need  today 

-  It’s  easy  to  change  into 
what  they  need 
tomorrow 

-  All  users  and  all  parts 
working  together  as  a 
seamless  whole 

-  Affordable,  on  schedule, 
etc... 


We  couldn’t  build  that 
perfect  system  yesterday 

-  And  still  can’t  today 
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The  Past  Compromise 
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•  Instead,  we  organized  the 
world  into  program  offices 
that  built  separate  C2 
systems 

•  A  program  built  a  system 
for  its  users 
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The  Past  Compromise 


network 


DBMS 


Internet 
Yellow 
Pages  „ 


directory 


Instead,  we  organized  the 
world  into  program  offices 
that  built  separate  C2 
systems 

A  program  built  a  system 
for  its  users 

-  All  the  mission 
functionality  they 
wanted 

-  All  the  infrastructure 
they  needed 
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•  Instead,  we  organized  the 
world  into  program  offices 
that  built  separate  C2 
systems 

•  A  program  built  a  system 
for  its  users 

-All  the  mission 
functionality  they 
wanted 

-  All  the  infrastructure 
they  needed 

-  Delivered  as  a  single 
amalgamation 
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The  Past  Compromise 


Hundreds  of  C2  systems... 


Instead,  we  organized  the 
world  into  program  offices 
that  built  separate  C2 
systems 

A  program  built  a  system 
for  its  users 

-  All  the  mission 
functionality  they 
wanted 

-  All  the  infrastructure 
they  needed 

-  Delivered  as  a  single 
amalgamation 

And  other  programs  built 
other  systems  for  other 
users... 
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A  Forest  Of  Stovepipe  Systems 


Coalition 
Enterprise 
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The  C2  Enterprise  Integration  Problem 


It’s  difficult  for  these  people 
to  work  together 


Because  it’s  hard  to  make 
the  systems  they  use 
interact  with  each  other 
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•  Hard  to  connect  separate 
C2  systems 

—  Different  infrastructures 

•  Hard  to  make  systems 
exchange  C2  information 

-  Shared  semantics  are 
difficult  to  arrange 

•  Hard  to  administer  groups 
of  C2  systems 

-  Each  system  needs  its 
own  sysadmin  staff 

•  Hard  to  manage  change  in 
C2  systems  and  functions 

-  Inflexible  interfaces 

—  Rigid  infrastructure 
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Unhappy  users 

Important  C2  capabilities 
that  we  can’t  afford, 
or  build  at  any  price 


Inflexible,  stovepipe  systems 
Co-evolution  is  impractical 
Delay  in  achieving  NCW 
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The  C2  ERA  Solution 


•  Change  how  we  organize  C2  enterprise  acquisition 

-  Manage  programs  and  systems  as  components  of  C2  Nodes 

•  Change  how  we  build  the  individual  C2  applications 

-  Don’t  build  separate  infrastructure  for  each  system 

-  Deliver  applications  that  share  a  C2  Node  Platform  and  a 
Common  Integrated  Infrastructure 


Two  different  changes. . . 
both  built  around  the  same  C2  Node  concept 


M  ITRE 


13 


First  Change:  How  We  Organize  Acquisition 


Begin  with  users  that  must 
cooperate  closely 


Program  offices  build 
the  applications  that 
those  users  need 

C2  Node  Manager  ensures 
that  those  applications 
are  seamlessly  integrated 
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First  Change:  How  We  Organize  Acquisition 


Begin  with  users  that  must 
cooperate  closely 


C2  Node 

(Weapon  System) 


Program  offices  build 
the  applications  that 
those  users  need 

C2  Node  Manager  ensures 
that  those  applications 
are  seamlessly  integrated 


And  delivers  integrated 
applications  as  a  cohesive 
C2  weapon  system 
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First  Change: 


C2  Node 

(Weapon  System) 


How  We  Organize  Acquisition 


C2  Node 

(Weapon  System) 


Repeat  for  each  distinct 
C2  Node  User  Community 
and  each  C2  Node  Capability 

Operational  concerns 
dominate  the  selection 
of  C2  Node  boundaries... 

But  technical  concerns 
can’t  be  ignored  -  because 
you  must  be  able  to  build 
the  “weapon  system” 
you  want 


Result:  Many  fewer  C2  Nodes...  better,  but  still  not  good  enough 
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Today’s  Enterprise  Integration  Problem 


Operational/Domain 
Focused 


Systems/Technology 

Focused 


10s  of  Capabilities  (n) 
1000s  of  Systems  (m) 
10,000s  (n*m)  of  Integrati 
Points 
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C2  Node  Impact  on  Enterprise  Integration 
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C2  Nodes 


•  C2  Node:  A  set  of  materiel  and  non-materiel  solutions  that  is 
managed  as  a  weapon  system  and  provides  warfighting 
capability  at  a  specific  location  or  set  of  locations. 

•  C2  Nodes  are  defined  as  strategically  selected  integration 
points  to  implement  cross-mission  and  cross-capability 
integration 

•  Well  chosen  C2  Nodes  will: 

-  Display  operational  cohesion:  Have  users  who  need  to 
collaborate  closely  to  perform  their  missions 

-  Display  implementation  cohesion:  Collect  and  integrate 
mission  applications  which  must  work  together  seamlessly 
to  support  the  users 

-  Display  infrastructure  cohesion:  Collect  mission 
applications  which  can  be  implemented  using  the  same 
"C2  Node  Platform"  infrastructure 
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Users  and  Systems  Collected  Into  C2  Nodes 
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COI:  Community  of  Interest 
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Second  Change:  How  We  Build 


Most  program  offices 
build  mission  applications 

Applications  and 
infrastructure  are 
CLEARLY  SEPARATED... 

-  Apps  use  infrastructure 

-  Ideally  nobody  builds  both 


A  few  program  offices 
build  infrastructure 


M  ITRE 


21 


Second  Change:  How  We  Build 


•  Programs  build  mission 
applications  to  satisfy 
user  requirements 

•  Those  applications  must 
use  the  infrastructure 
specified,  built,  and 
operated  by  somebody  else 

•  We  can’t  build  a  single 
infrastructure  that  does 
everything  for  everyone, 

SO... 


C2  Node 


C2  Node 
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Second  Change:  How  We  Build 


•  We  split  the  infrastructure 
into  two  parts 

•  One  part  is  different  for 
each  node 

-  The  C2  Node  Platform 
is  chosen  by  each 
Node  Manager 

•  One  part  is  the  same  for  the 
entire  C2  Enterprise 

-  The  Common  Integrated 
Infrastructure  is  managed 
“like  a  node” 

•  The  C2  Enterprise  Reference 
Architecture  describes  the 
services  in  each  part 


C2  Node 


C2  Node 
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Information  Technology  Overview 


Global  Grid  -  seamless, 
enterprise  network 

Enterprise  directory  of 
people,  services,  etc. 

Component  frameworks  -  a 
way  to  build  applications 

XML  Web  Services  -  how 
C2  Nodes  interact 

Enterprise  info  assurance 
services 

Info  Assurance  constraints 
across  the  architecture 
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Why  Divide  The  Infrastructure? 


C2  Node 


C2  Node 


•  Why  have  Node  Platforms? 

Why  isn’t  everything  in  the  Cll? 

-  Dependencies  between  nodes 

-  Hard  to  change  and  evolve 

•  Why  have  the  Cll? 

Why  isn’t  everything  in  Nodes? 

-  Some  things  must  be  the  same 

•  What  makes  a  service  belong  in 
the  enterprise-level  Cll? 

-  Enterprise  essential 

-  Enterprise  control 

-  Enterprise  scale 

-  Enterprise  content  or 
connectivity 


M  ITRE 


25 


CII  Example:  Domain  Name  Service  (DNS) 


www . acc . af . mil 


DNS  belongs  in  the  CII  because: 

•  DNS  is  a  service 


*  Service  Request 
\  from  Anywhere  / 


Q:  What  is  the  IP 

address  of 
www . acc . af .  mil 

9 

■ 


A: 

131.6.12.199 


•  DNS  is  essential 

•  Nobody  builds  their  own  DNS 

•  DNS  is  available  everywhere 

•  It  is  the  same  DNS  everywhere 

•  The  DNS  content  is  created  by 
many  people 

•  All  this  works  because  the  rules 
for  connecting  DNS  servers  and 
for  creating  DNS  content  are  the 
same  for  the  whole  enterprise. 


Common  Integrated  Infrastructure 
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DNS  Is  More  Than  Software 
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DNS  Is  More  Than  Software  +  Hardware 


*  Service  Request 
\  from  Anywhere  / 


Common  Integrated  Infrastructure 
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DNS  Is  People,  Process,  and  Technology 


and 


'  Service  Request 
\  from  Anywhere  / 


and 
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Result  of  the  Two  Changes 


C2  Node  C2  Node 


•  Gather  together  (within  each 
C2  Node)  applications,  which 
formerly  were  separate  and 
independent 

•  Separate  each  application  from 
its  infrastructure...  things  which 
formerly  were  combined  together 

•  Improved  cohesion  between 
things  that  should  work  together 

•  Reduced  coupling  between 
things  that  should  change 
independently 

•  Better  functionality  and  flexibility 


New  technology  supports  these  improvements 
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C2ERA  and  GES  /  NCES 


Users 
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Common  Integrated  Infrastructure 


Community -of- 
Interest  (COI) 
Capabilities 

Levels  of 
Services  above 
core  level 

Comms 


Backbone 


Core 
V-  Enterprise 
Services 
(CES) 


—  Discovery  Collaboration  Storage 


App 


Global  Information  Grid  (GIG)  Enterprise  Services  (GES) 
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Summary 


•  C2ERA  makes  two  changes  to  C2  systems 

-  Manage  related  applications  as  C2  Nodes 

—  Separate  mission  functionality  from  infrastructure 

•  Infrastructure  separated  into 

-  Common  Integrated  Infrastructure  (CM) 

Same  for  the  whole  enterprise 

-  Node  platforms  -  can  be  different  for  each  C2  Node 

•  Consistent  with  new  DoD  approach 

•  Result:  better  functionality  and  flexibility 

•  Made  feasible  by  new  technology 
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